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(54) Method and apparatus for dynamically loading method call exception code 

(57) A method for handling method calls in a di-; . ,/ 
ent/server conputer system includes the step of receiv- 
ing at a server computer a method call generated by a 
client computer. The server computer then attempts to 
execute the method call and subsequently generates an 
exception. The exception is passed to the client compu- 
ter. TTie client computer matches the exception to 
exceptions in an exception list stored in the client com- 
puter to obtain an exception object identifier. The excep- 
tion object identifier is used to load exception code into 
the client computer. The exception code is then proc- 
essed. Thus, the exception code need not be loaded at 
the time of generating the method call. Instead, it is only 
loaded when it is required at run time. 
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Description 

Ihts invention relates generally to client/server computer networks. More particularly, this invention relates to a 
technique for loading method call exception code Into a client computer only when it is required at run time. 

Background of the Invention 

In a dient/sen^er conputer networK the user of a client computer requests the execution of an object In particular, 
the us^ requests the execution of a methpd associated with the object Frequerrtly the object is not stored locally on 
the client computer Thus, a remote procedure call (RPO nujst be made to a server computer on which the object 
resides. In most cases, the server computer executes the requested method to generate a result The result is then 
passed to the client computer. However, when the server computer cannot execute the requested method . or can only 
execute a portion of tfie request^ method, an exception i^ slaid to exists In tiiis case, the server computer notifies the 
client computer erf the exception, ft is then in<xin*ent upon the cljent computer to interpret the nature of the exception 
and take coirecBveactipn' V , ! ■ 

iln many distributed computer systems th^ support remote procedure calls, for example computer systems using 
the SOLARIS™ operating system in conjunction witti the>IAYA^ virtual machine environment, both from Sun Microsys- 
tems®, Inc., Mountain View, Califomia (SOLARIS^, JAVA™ and Sun Microsystems® are trademarks or registered 
trademarks of Sun Microsystems, Inc. in the United Stat^ and other countries), , when a client computer requests the 
execution of a method In an object (sometimes called jny^ng an object mettiod), the client computer Instantiate^ all 
the exc^on code associated witii that method. The exception code nrvght be stored locally on the diant computer, but • 
in pnany cases tfie exception code must be retrieved from a remote computer. Consequently, in most cases, by invoking 
an object, the cliertt conr^)uter must retrieve exception code from a remote cornputer. Initiating communication with the 
remote conputer and exchanging information with it is a relatively time consuming operation. 

Since in most cases tiie invoked method is. successfully executed, the method 6xces:Ftion code is not used by tiie 
client computer. Thus, the client computer expends valuable time loading exception code that is not n^ssary In \new. 
of tills situation, it would be highly desirable to provkie a technique lor loading method call exception code only in tiie 
event that it Is neiBded at run time. 

Summary of the Invention 

An en^odiment of the iovention includes the step of -i^^^en/ing at a serv^ conputer a metiiod call generated by a 
client computer. The.seryer computer then attempts to execute the method call and subsequentiy generate an excep- 
tion. The exception is. passed to the client conputer The client computer matches the exception to exceptions in an 
exception list stored in the.cjient conputer to obtain an exception object identifier. The exception object identifier is used 
to load exception code iritb the client computer. The exception code Is tiien processed In order to handle tiie exception. 
Thus, tiie exception code is not loaded at tiie tirne of generating the method ^11. Instead, it is only loaded when it is . 
required at run time. 

The apparatiis pf the invention may include a client computer that generates a method call. A server computer ,. 
receives tiie nriethod call from a ti-ansmission channel connected between tiie client computer and serx^er computer. 
The~semrl?onfput^^^ attem^j^tol>iTCes5"tiie and tfiereafter generates art excqptibn. T^^ 

passed over. the transmission channel to the client computer The client computer matches the exception to a set of 
stored exceptions. The matched exception, is associated witii an exception object identifier The exception object iden- 
tifier is used, to ibad .exception code. The client computer then processes tiie exception code, ttiereby responding to the 
exception generated by ttte method call. = : . . 

The client compiuters operate much faster because they load less information when a metiiod is invoked. Specifi- 
cally. they,only load the code for th,e method cail. In the relatively unusual event that the method call is unsuccessful, 
tiien tiie method exception code associated. 

Brief Description of the Drawinos 

Examples of ttie invention will new be described with reference to the accompanying drawings, in which: 

FIGURE 1 illustrates a client/server computer topology 

FIGURE 2 illustrates the processing associated witii the apparatus of Figure 1 . 

FIGURE 3 illustrates the processing steps associated with the protocol recognition methodology of an embodiment 
of tiie invention. 
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FIGURE 4 Illustrates an example of a data structure tfiat m^ be' used In practicing the disclosed technology. 
FIGURE 5 is a generalized r^resentation of a data staicture that may be used in practicing the disclosed technol- 
ogy. 

FIGURE 6 illustrates processing steps associated with the dynamic loading of exception code, in accoidance with 
5 one emk>odiment of the invention. 

Like reference numerals refer to conesponding parts throughout the several views of the drawings, 
Detailed Description of the invention 

Rgure 1 illustrates a client^server computer apparatus 20 incorporating the tedinology of the present invention. 
The apparatus 20 includes a set of cDerit oonputers 22A-22N. which are each linked to a transmission chanrie! 23. The 
trar^ission iehannel 23 generically refers to any wire or wireless link between computers. The dient conrputers 22A 
22N usie the transmission channel 23 to communicate with a server computed 24', br othear server computers desighat^di 
16 by server computer 24N. • • ; . . o / 

Each client computer 22 has a standard computer cbnfigumtlon 1^^ uriit (CPU) 30 con- 

nected to a memory 32. which stores a set of executable progran^s. TTie iakbc^iiblepfbgrams in this ep^nplary system 
include at least orid client applicatbri program 34. client stubs 38, cliertl suBcorrtmckji' 40, andlah operatihg system 4?.; 

The client application program 34 is any application-level program; such as an ^plicatipri;pfpg the user oif 

20 a client computer 22 intenacts with. The eiient stubs 38 rebeive i3ix)cedure dalls by the'ai^lijdfiiti^^^ rkiuesting, 
the execution 6f spedfied methods of specified objects, the purpose of the ciieht^Cibs 38 iW to'^cbess c^^ that are 
irrplememed in other address spaces, such as at server comput^^ ' '^^^ 

The dient subcontract programs 40 and ser^^r sutxontract programs 58 coritrot^^^ of object 

invocation and argument pasdngV They control how object invocation is implemented, ho\/v dbjfect r^erences are transT 
25 mittad between address spaces, how object references are released, and sinuW objed miffim eiaim-; 
p!e. wheni a clierit invokeis an object of a given subcoritr5.ctrthe si*contract irn^)l4rn^^^^ fnvbcation by 

transmittirig the request to the address space where the assodaled object is locate^rcommoHly the deiver conputer 

24. ' " '■■ ■ _ ■■■ ■ ' ■ ■ ' ' ■ ■ ' ■ ■ 

The client subcontract prolgrams 40 perform a miarshai operation to transmit an object iri^cK^ remote pro- 

30 cediire call) to anotfier address space! A corrisspbhding tihhfiarehalling operation Is performed by a 64rv€ir isubcontract 
58 on the server computer 24; The client subcontract program^ 40 also perform unrmrshal opeffilLtiqhs when receiving 
a reply (such as the results generated from a method calQ from another computer, say the server cdnputer 24. An oper- 
ating system 42. such as the Sun Microsystem's SOLARIS operating system, underlies the operations of the dient 
application programs 34, the client stubs 38, and the client subcontracts 40. 

35 The server 24 has a configuration analogous to that of the client computers 22. The server 24 indudes a CPU 50 
and an associated mernory 52. The inemory 52 stores server application programs 54, sever stubs 56, sender subcon- 
tract programs 58, and an operating system 60. As indicated abqvei the server stubs 56 handle incbming method invo- 
cations oh an object and call the specified methocf;tc jre-^dVm the operatibh. yte also Indicated above, the server 
subcontracts 58 perform data marshalling and other upi- ' .ii i to' support the transport of method irivocations and the 

40 resulting return messages between the server 24 and the clierrt computers 22. ' \ 

The operations of the apparatus of Figure i are more fully appreciated with referenbe to Figure 2. Figure 2 illus- 
trates the client computer 22A, the transmission channel 23, and the server 24 of Rgure 1 . As irtdicated above, a dient 
application 34 invbl«s a specified method of an object in a differerit address space ubihg a rerhote procedure call. The 
_jerTK>te_procedure_callis.passedby.the.d 

46 dure call for transport on the transmission channel 23. The servet subcontract 58 of the sbrver 2i4 redBiyes the inforrha- 
tion and unpackages it. The sen/er subcontract 58 then passes the Information to the server stubs 56. lite sender stubs 
56 access the server application programs 54» which are the previously descrbed object methods. MorS specifically, a 
spedfied server stub 56 makes a procedure call to execute a spedfied method of the involved object fhe'executiori of ' 
the method produces a set of results, herein called a reply, which is then passed back to the sen/er subcontract 58 and 

50 thecommunicationpathisreversed, as indicated by the arrows of Figure 2. 

Block 70 of Rgure 2 illustrates the components es?:c : sted with an Object Request Broker (ORB) of the irrvention. 
As indicated above, a wide variety of communication p . •:: :^;s are used on ORBs. The use of different protocols ori dif- 
ferent ORBs results in difficulties when a server attempts to recognize incoming object requests. . . 
The general architecture and processing assodated with the embodiment has now been disclosed. Attention pres- 

55 ently turns to a more detailed consideration of the architecture of the embodiment, the processing of the embodiment, 
the distinctions between these elements and conresponding elements in the prior art. and the advantages associated 
with the disdosed technology 

As shown in Figure 2, a client subcontract 40 uses a protocol-dependent method descriptor to request a method 
assodated with an invoked obied. More particularly, the client si4)contract 40 uses a marshal buffer that obeys a 



3 



, EPa767428A1 

selected on-^iMvIre data format. For exampjeHto idertlfy a given method "X", one protocol might use a value of 'OOCX", 
anoft'er might use a value "(^®;:123::>0CX". and another might use an integer value "123456" where the value is 
the output of a hash function, on the method name. The client stid} 38 passes to the client subcontract 40 a list of pro- 
toooKlependent values from which the client 8ut»ontract 40 computes the protocoi<lependerrt method descriptor. 

5 Thus, when a set of client computers 22A-22N are connected to a server 24, the server 24 must process each pro- 
tocol. Separate saver sitocontracts 58 (not shown) are necessary to accommodate each of these protocols. In the prior 
art each server sutjcontract 58 has a set of con^esponding server stubs 56. Thus, to support ORBs with multiple pro- 
tocols, a server 24 should have different server stubs 56 for each protocol, resulting in a large set of server stubs 56. 
ConsequenOy, it can be readily appreciated that the use of different ORB protocols can result in unwieldy requirements 

10 for the saver 24. 

In accordance with the present embodimart, when the server subcontract 58 receives an incoming method call it 
unmarshals the mettiod descriptor in a way that is specific to the subcontract's protocol. It ttien tries to match the 
method descriptor witti each of the entries in a list of protocol-dependent values: Protocol-dependent values can be 
character strings, numeric values, as well as other types of parameter values. Different protocols may use different 

IS matching functions to compare the method descriptor with the list of protoco Wependent values. The matching function 
may by a siring comparison, a hashing function, or other technique spedfied by the server subcontract 58. When a 
matching protocol-dependent value is identified, the server subcontract 58 can then associate it with an index value. 

As. shown in Rgure 2, the index value is~ passed to protpcd-independent sender stubs 56 ttiat can invoice the 
method corresponding to the irrfex value. In ttiis way, the protocol deperxlendes of the individual object references are 

20 insulated from tiie protocol-independ^ server stubs 56. Cor^equently, protocol-rndependent server stubs 56 can be 
used with any type of p^jert request broker 70. Furthermore, a single compiler may be used to generate the protocol- 
IrKlependent sen/er stubs 56. . . 

thus, unlike the prior art, the presertt enhbodiment provides a server 24 that recognizes a variety of ORB protocols.. 
Moreover, H perforn^ tihfis fMnction in a highly effective manner by using a single set of protocol-indeperident server 

25 stubs 56. Note ttiat to support this technique, the marshaHIng and unmarshalling operations commonly employed by 
prior art stufcis are pi^rbrriied by tiie client sulxontract 40 and server subcontract 58 of the invention. This trarisfer of 
processing arid the use of an index value to provide protocol-independent server stubs constitute differences between 
the prior art and one embodiment of the present inventfpn. Thus. thJs embodiment the present invention can be suc- 
cessfully Implemented in existing architectures and processes, once these processing differences are accommodated! 

30 Rgure 3 provides a detailed migration of the processing steps described In the foregoing paragraphs. The first- 
processing step of Rgure 3 is that the sender subcontract identifies a method descriptor in a method call (block 80). As 
indicated above, the client computer produces a method call, which is ultimately packaged in a rmrshal buffer as a set 
of information. The content of the infomiation is contingent upon the client subcontract that has marshalled the informa- 
tion. The corresponding subcontract at the server unmarshals the information and recognizes, witfiin the information^ 

35 the metiiod desaiptor 

The next processing, step is for the server subcontract to select a protocol-dependent value ttiat matches ttie 
method descriptor (bio* 82). This operation may be illurtrated with i'eference to Rgure 4. Figure 4 shows a 
Descriptor_Ust of protocol-dependent values. This list includes N subset lists. Each sutiset list identifies a set of proto- 
col-dependent values tiiat may be used to identify a single mettiod. Each subset list has j entries. In Figure 4. Jhese 
40 entries are shown as Descriptor_IJst_1_1 through Descriptor_L!st_1 J- In Rgure 4, Descriptor_IJsL1«1 is associated 
witti an Interface Definition Language (IDL) Short Name. IDL is a standard used in tiie art. That is, one entry in tt?e list 
is the IDL short name for tiie invoked method. The IDL Short Name Is an ORB protocol name used in ttie art The same 
list shows ttiat Descriptor UsC1~2js a5Soa 

name for the invoked method. The IDL Long Name is another ORB protocol name used in the art. The third entry in ttie 
4S subset list is Descriptor_List^1_3, which has a repository ID. The repository ID is a name used in anottier ORB protocol 
in ttie art. Bcanples of these differem proioools indude the following statemem^^^ 

'*get_weak_comparator'? (IDL Short Niame), 

so **::comparator::weak_comparable::get_weak_ra 

(IDL Long Name), and 

"IDL:/comparator/weak_comparable/ge^_vveak_conripa^ 
55 (Rqwsitory ID), 

which are used to invoke the operation: 
get_weak_comparator. 
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As Indicated in Rgure 4, alternate designations may also be us4d In the list of protocol^lependent values. In addi- 
tion, the designations shown by e)ample herein need not be used. In any event using theformait estabGshed by the IDL 
standard andiiherindustry standards and practices, It is possible'to predict the nwiner In whic^ most method descn|> 
tore vvlil be imjplemerited by any reasonable protocol 
6 The fdliqytnng pseudocode is used as a simp^^^^ 

. il) i =0 - . ■ 

(2) match = false 

(3) repeal 

(4) i = i + 1 

. (5) if Match J) (Method^Descriptor, Descriptor List J j) 

(6) Then Match = True 

IS (7) until Match 

(8) call operationjrable(i) / : 



20 Lines (1) and (2) provMe initialisation. Lint) (3) Is the ontry in^o a processing loop Une (4) provides inttializaton 
within the processing loop. Une (5) tects for a condition: Namely, the cod6 tests if the unmar^hali^ 
"Method^Descrlptor" of the method call matches the ;th cnir> of th© "Ith" subset list (Descrlptor^LteLiJ of the proto- 
col-depemiml Sst The "jth" entry, say tfie !DL short ramG, Is kna*ri from the sender siAcontmct 58 tb be the one to 
compare for this protocol. The W value Is an incremented value that allows each subset descriptor list 
zs (Descriptcr_Usi_1 trough Deccrtptor^UsLN) to be tested. The term ''Matci iip- refers to the matehiilg fimcBon that Is 
usod to compare the Method_Descriptor to the list aitry. For instance, *^atdiip" might spedfy a simple string corhpar- 
ison between values, or it might specffy the comparison of hash values. The definition of "MatdiJ>" W provided by the 
server subcontract 58. • ' ^ 

If the condition Is met. then a match is found, othenMse, the nexii subset list T Is accessed^ Wheh aniatch is found, 
30 then line (3) provides a call to an operation table of the server stubs (56). Note that the value T When a match Is found 
is Ihe vahie passed to the server stubs. Tills value corresponcte io a subset of tfie searched Hst, and this slibset is asso- 
ciated with a single method that has been called. Thus, tl;e c^e at line (8) illustrates the next processing step of Rgure 
3, namely that the server subcontract passes an index value to the server stubs (block 86). 

Once the cerver stubs receive the index value, they rety upon an operation table 100, shown in FIguire 4, to invoke 
35 the metficd spedfied by the index value. The operaticr . i preferably implemented as a case table ttiat has a set 
of processing steps associated with each case value : . an the value 1- is received, the method specified by the 
value is executed (block 88). Rgure 4 illustrates a simple set of processing steps to achieve this result The first step is 
to execute method I, and the secotxl step Is to load ail resulting messages (the reply) in^ the marshal buffer. The final 
processing step shown in Rgure 3 is for the server stubs io pass tite reply generated from the execution of the method 
40 to the server subcontracts (block 90). 

Rgure 5 illustrates that lihe embodiment supports the exceptions associated with method calls. In prior art systems 
of the type discussed above, exception code associated with a method is loaded before the rhethod is invoked. For 
example, vvt.en a method is invoked ir^ a prior art system, the client computer 22A loads the code for all exceptions 
as6odated with the method call before g eneratin g an RPC t o execu te the met hod. 



45 Mora specifically, for each possible exception condition, there is a corresponding object class. When an exception's 
object dass Is instantiated, an object instance is treated that includes a method (I.e.. an executable program) for 
responding \o or othenmsa processing !he corresponding exception. Tlius, in the prior art system, when a client appli- 
cation program initiates an RPC to invoke an object method, if the RPC references a long list of exception object 
classes, all those exception object classes will need to be instantiated in the address space of the client application pro- 

so gram 34 before the RPC in the client subcontract 40 can sven transmit the method calf to the sender computer 24. 

While the exception information for some of these exceptions (i.e., instances of some of the exception object 
classes) may be available on the client computer 22, in most cases at least some of the exception object classes will 
not be resident on the client computer 22. For those exceptions that do not have conresponding exception procedures 
(i.e., exception code) on the client computer 22, the dlent computer 22 is forced to retrieve the exception procedures 

55 from remote computers, such as server 24N. shown in Rgure 1 . Furthermore, a saparats communication session is typ- 
ically required to obtain each exception procedure (i-e.. exception code). Consequentiy, the process of gathering excep- 
tion code can be relatively time consuming. This processing penalty is especially unfortunate since in most cases the 
exception code is not required by the dient computer 22. 

A method call in the present embodiment does not reference eadh exception assodated with the method call. Con- 
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sequenUy, the different exceptions are not loadi^'irifHaliy. Ihey are only loaded If an exception Is tfeliy^reci. Thus, with 
the present embodiment only the method call fe processed initially, resuWno In faster pertbrmahce The Ih^iroved per- 
formance is only unavailable in the relatively rare event that an exception is processed. 

As shown in Rgure 5. each identified method, say the method associated with Descriptor.LisU. has an associated 
exception descriptor. The exception desaiptor is a pointer. For example, relying upon the "getjweaKconparator" 
example above, tfie exception descriptor is 
jae|Lw6ak_conparatorExceptionDescrqrtorlnstance. 

The exception descriptor points to an inception list that has M exception subset lista Figure 5 .shows 
Exception_Ust_x. Each subset list specifies one of the exceptions to the method call Including the |PL short name, IDL 
long name, a repository identification, and any alternate identification ter the exception. Each exception list also 
includes an exception object identifier, which is i^ed to locale exception code at mn time. 

The ex^on descriptor concept used in this embodiment of the invention is shown in Figure 4. Note that the last 
entry in the subset descriptor list "DescriptorlUst.l " is an ^ception descriptor that points to an exception list The reply 
generated by the sewer computer when executing a method may Include any one of the entries within the Exception 
list say, the exceptions associated with Exception_UsL1p Exc^on_Ust.3, or Exception_UsLM. A specified server 
subcontract 58 uses its assodated protocol to transmit the exceptions. The dient computer 22 then receives the excep- 
tions from the seryer computer 24. 

In accordance with the present emjDOdiment the dient subcontr?ict 40 stores a copy of the exception list associated 
with an exception descriptor. Thus, when the exceptions are received from the server computer 24, the dient computer 
22 can inatch them to the e)Qceiptions in the'exception lisl. using the technique previously disclosed in relation to klenti- 
fying methods. 

The exception is then processed by relying upon an exception object Identifier, which Is used to retrieve the excep- 
tion code assodated with the exception. Note in Rgure 5 that Exceptioh_UsLx, like all other exception subset lists, 
includes an exception ot^ecl identifier (Exc^on Object ID), which is a sfring name that specifies the object class to 
handle the exc€ptioa The code fqr the object dass may be In a local object repository 104. In the event that the object 
do6s not reside in the lo<^ object repository 104, the operating system.42 instaritiates the objeqt into the local object 
repository 104 by downloading code from ariother computer on the network, say server 24N of Figure 1 . Thus, the 
remote object repository 106 of Rgure 5 refers generally to any computer that is called to provide code for an object. 
The code is then directed into the local object repository 104. The process of fetching code from the local object repos- 
itory 104 and the remote object repository 106 is similar to prior art approaches, but the operation in the present Inven- 
tion is executed after an exception has been returned, in^ead of wheri the method descriptors are constructed. 

The foregoing disdosure of an embodiment of the irtventibn is summarized in reference to Figure 6. The first step 
associated vwth the process of Figure 6 is to generate a method call at a dierit computer 22 (block il0). As indicated 
above, the method call of the embodirnent does not instantiate an exception's object dass. Thus, the method call is han- 
dled without instantiating exception objects. 

The next processing step is to process the method call at the server computer 24 (blod< 1 12). As indicated above, 
the attempt to process the method call results in the sender computer 24 Wentifying an exception. The exception is then 
passed to the client computer 22 (block 1 14). 

When the client wimputer 22 receives the exqeption, it attempts to match it to the exceptions in the exception list 
that it stores (block 116). Each subset of the exception list (say, Exception_IJst_M) is assodated with a single exception, 
and each subset has a corresponding exception pbject identifier (Exception_ObjecLID, as shown in Figure 4), The . 
exception object identifier is used to load exception code into the dient computer (block 1 18), Rnally, the dient cornpu- 
- ter prpcesses:the e)pption code to' r 

In view of the fbregolhg, the benefits of the present errfcodiment are manifest. In accordance with the embodiment, 
dient computers 22 opiate much faster because they load less information when a method is invoked. Specifically, 
they only load the cojde needed to propess the method call. In the relatively unu^jal event that the method call is unsuc- 
cessful, then the.excep^pn code associated with the method is e)qpeditiously loaded! 

Claims ' ' *■ " ' '-'^ 

1. A method for handling method calls in a client/server computer system, said method comprising the steps of: 

matching an exception generated by a server computer to exceptions in an exception list to obtain an exception 
object Identifier; 

loading into said client computer exception code corresponding to said exception object identifier: and 
processing said exception code to respond to said exception of said method call. 

2. The method of claim 1 further comprising the following steps performed before said matching step: 
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receiving at a server conputer a method call generated by i client computer; 

aiterpting ltp execute said nrieth 

gerie^^firiia an excepti 

passirtfi said ewseption to said dieht cpnn^ 

3. TtiiB method of daim 2 wherein said passing step inducSes the stiBp of passing said exertion In a protocol-depend- 
ent fbritiat. 

4. The method of daim 2 wherein said matching step indudes me step of using an exception list with a plurality of 
subset lists; each 6f said subset lists corresponding to a specified exception and including a set of entries corre- 
spbndir^ to diffe^rent proloco Weperri 



5. The method of claim 2 wherdn said loading st^ indudes ttie step of loading said iaxc^ption code from a computer 
other than siald dient conputer when said exception code is not resident on said client conputer. 

6; The method of daim 2 furtlier comprising the^s^^ " ^ ' 

locating within said metiiod call a method descrij " '^jpeScified in a protocibi-di^enderrtfo^ 
assigning an index value upon matching said method descriptor to a selected proitotiolrdepehdent statement in 
20 a list Of protdcoWep^dem Statement; a^^^ ' ! " r ^ ^ 

passing said index y/^ue to a protocd-ind^eh^^^^ senirer (ibftpL^^^^ said 

computer server returns to said diem c6rti)iitef^^^^ 

7. A computer readable meniory thert can be used to direct'a dieiit^^ system tp furidtion ih,a sp^ified manner. 
25 ■■ comprising: /- ■ ' V'..,r-' '■" • v"'"',' ' * 

method exception informiatiori stor«^ menioi'y, ^aid hiefthod ^ception ihforhfiatiori iriijluidihg an excep- 
tion list spefciiyir^ a 4et *of exceptions; and/portable instructions storki in said memory, said'acecutable 
instructioris including: " ' ; . ; : - : ; ; ; 

instructions to generate at a seiyer corTiputGr of a'dierit/server system an exception in response to a 

nriethod call fromi dient conri'p^^ 

instructions to pass said exception from said S6r^^^ 

instruction^ to match skid exception td exceptidns in said exception list to forrh ah iaxceptidn objed identi- 
35 iier; ' ' ' • ■ 

instructions to load into skid client computer exception code corresponding to isaid exception object iden- 
tifier; and 

instructions to process said exception cod^ 

40 8. The computer readable memory of daim 7 wherein said instrudions to pass said exception from said server com- 
puter to said client computer include insti^uciions to pass said exception in a protocol-di3pendent format 

9. The computer readable memory of daim 7 wherein said insti-uctions to match said excieption to exceptions in said 
^exceptionJisfcj'ndudeinslrucUoris-to-use an-exceptior^i^^ 



45 con;e8pondirig to a specified exception and induding a set of erifries corresponding to different protocol-dependent 
statements used to characterize said specified exception; 

10. The computer readable memory of claim 7 wherein said Instiructions to load into said dient computer exception 
code corresponding to said exception objdct identifier indudes inistructions to load said exception code from a com- 

60 puter other than said client computer when said exception code is not resident on said client computer. 

1 1 . The computer readable memory of daim 7 furtiier comprising: 

instructions to locate within said method call a mettiod descriptor specified in a protocol-dependent format; 
55 instructiorre to a^ign an index value upon matching said metfiod descriptor to a selected protocol-dependent 

statement in alist of protocoMependentsrT < : : -id 

instructions to pass said Index value to a pre , dependent processing module of said sender computer, 
wherein said conputer server returns to said client computer a reply based upon said index value. 
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